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5 Cross-Reference to Related Applications 

This is a divisional of U.S. Application No. 09/160,642 filed 09/24/1998 by 
the same inventors, and claims priority therefrom. 

Field of the Invention 

10 The present invention relates to software for interactive communication 

with a machine, such as a copier or printer, enabling remote status inquires and 
maintenance of the machine. Specifically, the present invention relates to a 
specific architecture for such software which facilitates many practical 
advantages. 

15 

Background of the Invention 

With the increasing sophistication of office equipment, such as digital 
copiers, printers, facsimiles, as well as devices which combine many of these 
functions, individual devices become more and more software intensive. Much 

20 of the functionality associated with a particular device dwells in the software of 
the device, and functionalities of a device can be monitored, improved or 
increased via the machine software. Preferably, such software access could be 
performed, for example, by a tech rep attending the device and plugging in a 
personal computer or laptop into the device for direct access to or downloading 

25 of software; or, the software could be accessed or installed in a device remotely, 
over a network. 
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Whatever the specific physical means used to access the internal 
software of a particular machine, it is most desirable to provide a common 
"application" enabling a human user to view and if necessary alter the machine 
conditions through the user's computer. It is most desirable that the application 

5 for interacting with a particular machine be indifferent to the specific physical 
means (network, modem, direct connection, IR, etc.) by which a particular 
machine is accessed. 

Further, it is likely that a relatively large population of machines, such as 
digital copiers or printers, may be accessed in various ways by a relatively large 

10 population of human users or administrators. Depending on the level of 
interaction with the internal software of various machines, it may be desirable to 
give some human users, such as administrators, fairly detailed access to the 
internal software of a particular machine (e.g., voltage levels within the printer 
hardware, analysis of the long-term use of the machine), while other users are 

15 given only limited access to only the most basic software functions (e.g., simply 
determining whther a printer is available for use). Of course, there is also a 
necessity to give some users access to only some machines, with different users 
access to other machines. There is thus a need to set-up what is in effect "read" 
and "write" privileges relating various users to specific functions within various 

20 machines. 

Description of the Prior Art 

US Patents 5,038,319; 5,057,866; 5,138,377; and 5,339,168 are 
examples of basic concepts of "remote interactive communication" with 
25 machines such as printers and copiers. 

The article by Bylinsky, "Fixing Machines From Afar," Fortune, August 17, 
1998, page 174[B], describes a number of techniques currently available for 
remote repair, diagnostics, and maintenance of various complicated machines. 
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Summary of the Invention 

According to one aspect of the present invention, there is provided a 
program, operable on at least one computer, for accessing machine software 
operative of a machine. A protocol layer converts data derived from the machine 
5 software to a set of function calls, the function calls being exportable to an 
application for viewing on a user interface. A system interface applies a set of 
permissions to the function calls from the protocol layer, whereby only a 
permitted subset of function calls may be exported to an application. 

10 Brief Description of the Drawings 

Figure 1 is a simplified systems diagram showing various techniques for 
accessing machine-based software for purposes of remote repair, diagnostics, 
and maintenance; and 

Figure 2 is a diagram showing the architecture of the software according 
15 to the present invention. 

Detailed Description of the Invention 

Figure 1 is a simplified diagram showing how a number of reasonably 
complex machines, in this case digital copiers 10a, 10b, can be accessed in 

20 various ways while they are being used by customers. In brief, machines such 
as digital copiers include a great deal of internal software for operation of the 
electromechanical systems therein. This internal software can be accessed in 
various ways, such as to detect failures, determine when regular maintenance is 
necessary, and even to alter the operation of the machine remotely. 

25 Typically, in the context of office equipment, there are any number of 

ways in which the internal software of a machine such as 10a, 10b could be 
accessed. As most digital printing equipment is based on a network, the 
machine could give access to its internal software through a network 12 which 
connects to any one of a number of computers such as 20a, which may be 

30 located anywhere in the world. A customer service engineer (CSE) or "tech rep" 
can come out the customer site and directly couple his laptop computer, such as 
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20b, directly to a port in the machine 10a, or a computer such as 20c can 
interface with the machine 10a through a modem 14, using telephone lines. 
Alternately, a tech rep can access a suitably-equipped machine such as 10b with 
an infrared (IR) communication link, as shown. 

5 The present invention is a software architecture which allows different 

users to have different levels of interaction with different machines, and also 
allows certain users to access only a subset of machines needed for particular 
business purposes. Also, the present invention facilitates a common 
"application" for user interface, which can be used by all users, whether remote 

io or directly connected to the particular machine, in which the actual connection to 
the machine is essentially invisible to the user. 

Figure 2 shows the basic architecture of the software according to the 
present invention. As shown, the software is generally indicated as 20, which is 
intended to mean that the software 20 can reside on any type of personal 

15 computer or laptop such as the computers 20a, 20b, 20c, or 20d in Figure 1, or 
even on the user interface of a machine itself. Once again it is an essential 
feature of the present invention that the basic software can reside on any 
computer and needs only minimal modifications depending on whether the 
software is for remote, network, modem, or other kind of access to one or more 

20 machines. 

According to a preferred embodiment of the present invention, the 
software residing on a particular computer 20 has four layers. Significantly, 
according to the present invention, these four layers are distinct from each other 
in that they interface with each other exclusively through distinct channels, so 

25 that, for example, information in a particular level must travel through intervening 
layers in order to get to another layer, as shown. (It is also conceivable that 
different layers can reside on different "computers" or CPUs, with for instance 
one layer on a tech rep's lap-top and another layer operating on the CPU within 
a machine 10 itself.) Device-dependent layer 22 interacts through a port 24 with 

30 the machine software in a particular machine 10. (In the context of office 
equipment a particular machine 10 may further include a quantity of memory in a 
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"consumer replaceable unit monitor," or CRUM, indicated as 1 1 and which will be 
explained in detail below.) For purposes of the present discussion, the port 24 
can be any type of machine interface suitable for accessing the machine 
software: the port 24 could be a direct cable connection, a network, a modem, IR 
5 interface, etc. 

The function of the device-dependent layer 22 is to convert data from a 
machine 10 coming through port 24 to a uniform format, regardless of the 
particular mechanism of port 24. For example, if the port 24 is an infrared link, 
the actual binary data from a particular machine 10 may be of a specific format in 

10 order to enable the IR link; yet another format for port 24 may be required when 
the data from machine software 10 is sent over the internet (in the claims herein, 
the different formats for different communication means are called "port 
formats"). The device-dependent layer 22 converts the data from port 24 to a 
standard format, so that the rest of the system is thereby indifferent to the 

15 physical nature of the port 24. In brief, device-dependent layer 22 may include 
any number of look-up tables for converting raw data from one of any number of 
port formats into a standard format. 

Once the data from machine 10 is converted by device-dependent layer 
22 to a standard format, the data can be accessed by what is here called a 

20 protocol layer 26. Protocol layer 26 packages data so that the source of the data 
(in this context, a particular machine 10), and the destination of the data 
(typically a particular application program on a particular computer 12, the 
computer itself possibly being on a network), along with the suitable data format, 
can be determined. Protocol layer 26 is thus essentially a set of application 

25 programming interfaces, or API's, which convert the data in standard format from 
device-dependent layer 22 into a series of function calls, which could be 
accessed by an application program for viewing through a user interface, such 
as on a computer 20. 

System interface 28 determines what data from protocol layer 26 can be 

30 exported to a particular client, and converts the data from protocol layer 26 to a 
client-desired format for viewing. The system interface 28 thus requires a set of 
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permissions which match the ID's of a particular user using a particular computer 
20 with the ID's of particular machines 10 to which the particular computer 20 
can access; further, the system interface 28 can allow a particular user to access 
only a subset of all possible function calls which are present in protocol layer 26. 
5 These permissions can be essentially permanently associated with a particular 
computer 20, or can be established over a large number of computers through a 
system administrator, through means known in the art. 

The top level of the software in computer 20 is an application layer 30. 
Basically, the application layer 30 is simply a user interface program by which a 

10 permitted subset of function calls (that is, the function calls which system 
interface 28 permits a particular user to view from protocol layer 26) can be 
viewed by a human user. The human user can be a systems administrator, a 
customer service engineer or "tech rep," or the end user of a particular machine. 
When a user (whether a tech rep, systems administrator, end user, or 

15 third-party tech rep) accesses a machine through computer 20, the user typically 
submits via application layer 30 a user ID and/or an ID relating to a particular 
machine desired to be accessed. It is possible that submission of a user ID to 
system interface 28 may cause system interface 28 to automatically identify one 
or more machines on a network that user is permitted to access. The system 

20 interface 28 also identifies, based on the user ID, which subset of function calls, 
relating to which functionalities in a machine 10, the particular user is permitted 
to access. Typical "functionalities" which relate to the function of a machine 10 
that a user may wish to view include (in the office-equipment context) the 
number of prints output since last access; average number of prints per day; 

25 fault codes recently generated by the machine's internal software; and 
information about replacement of various parts. Each of these functionalities 
relate to one or more function calls which are made available by the protocol 
layer, having been ultimately derived from the machine software 10. 

However, in real-world situations, it may be desirable to permit, for 

30 instance, only systems administrators, and not end users, to view certain 
information. Also, function calls can, in a preferred embodiment, be used to 
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send data to machine software, such as to reset or correct the operation of a 
particular machine; one would want to restrict the ability to move data to the 
machine software to qualified tech reps. For this reason, it is important that the 
permissions system in system interface 28 be able to restrict to which machines 
5 a user has access, and also which functionalities a user is allowed to access or 
use in a machine. 

Because system interface 28 can use a system of permissions to permit 
access by a particular user using computer 20 to only a particular machine or set 
of machines 10, and/or a particular set of function calls from protocol layer 26, 

10 facilitates any number of important business arrangements which are useful 
particularly in the office equipment industry. For example, the permissions within 
system interface 28 can be designed to restrict the operation of a particular 
computer 20 to, for example, direct connection only, preventing a particular 
computer 20 from remotely accessing a particular machine 10 such as through a 

15 network 12 or even through a modem 14. The system interface can selectably 
restrict a particular computer 20 from accepting certain software upgrades or 
wizards such as available through network 12. 

Also shown in Figure 2 between various layers such as protocol layer 26 
system interface 28 is capability for exchanges of "internal ID's" between various 

20 layers. For instance, there could be a provision that the system interface 28 can 
obtain a particular function call from protocol layer 26 only by submitting an 
internal ID number from the system interface 28 to protocol layer 26; such an 
arrangement could be a vehicle for restricting a particular user from accessing 
function calls in protocol layer 26 relating to certain non-permitted functionalities. 

25 To take another example, submission of a certain user ID or machine ID to 
application layer 30 may cause application layer 30 to activate suitable internal 
ID's for accessing function calls through system interface 28. Application 30 may 
have to submit an internal ID (which may be tied to the particular hardware on 
which application 30 resides) to system interface 28 to obtain any access to 

30 system interface 28. 
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The internal ID system can be used to facilitate certain types of use 
restrictions on certain computers 20: for instance, if a particular computer 20 is 
resticted to local use only, device-dependent layer 22 may require submission of 
an internal ID (ultimately from system interface 28, where it may not exist, if the 

5 particular computer 20 is restricted) to device-dependent layer 22 before 
activating parts thereof which enable remote (network or modem) connections to 
a machine. Preferably, this exchange of an internal ID between these two layers 
is completely invisible to a user viewing application 30. This feature makes a 
computer 20 operating machine 10 substantially more difficult to "hack," that is, 

10 to permit a user to obtain access to functionalities in the machine software to 
which he has not been given access. 

Also, for various reasons it may be desirable to require internal ID's to be 
submitted "upwards" in the direction of the Figure: for instance, device- 
dependent layer 22 may have to submit an internal ID relating to a particular 

15 machine 10 up to system interface 28 (via protocol layer 26, in the illustrated 
embodiment), as a means of preventing a machine 10 which is not on a service 
contract from sending a hardware error message ultimately to an application 30. 

In terms of restricting the particular functionalities, in terms of sets of 
function calls from protocol layer 26, to which a particular user can have access, 

20 typical types of function calls which would be restricted to a particular user may 
include: the billing data; a customer profile (that is, a record of how often a 
particular customer is using a particular machine); and data which may be stored 
in the customer replaceable unit monitor (CRUM) 11 which is installed in the 
machine 10. Very often, particularly in office equipment, a replaceable unit in the 

25 machine, such as a toner cartridge or fuser unit, may include a chip thereon, 
typically comprising an EEPROM, which functions as a "odometer" for the 
replaceable part (showing the accumulated wear or use of the part), or else may 
contain information relating to the desired use of the particular part (e.g., how 
much voltage should be sent to the part). 



While this invention has been described in conjunction with various 
embodiments, it is evident that many alternatives, modifications, and variations 
will be apparent to those skilled in the art. Accordingly, it is intended to embrace 
all such alternatives, modifications, and variations as fall within the spirit and 
5 broad scope of the appended claims. 



9 



